                                             
IBIS Macromodel Task Group

Meeting date: 08 Nov 2011

Members (asterisk for those attending):
Agilent:                    * Fangyi Rao
                            * Radek Biernacki
Altera:                       David Banas
Ansys:                        Samuel Mertens
                              Dan Dvorscak
                            * Curtis Clark
Arrow Electronics:            Ian Dodd
Cadence Design Systems:       Terry Jernberg
                              Ambrish Varma
Celsionix:                    Kellee Crisafulli
Cisco Systems:                Mike LaBonte
                              Ashwin Vasudevan
                              Syed Huq
Ericsson:                     Anders Ekholm
IBM:                        * Greg Edlund
Intel:                        Michael Mirmak
LSI Logic:                    Wenyi Jin
Mentor Graphics:            * John Angulo
                              Zhen Mu
                            * Arpad Muranyi
                              Vladimir Dmitriev-Zdorov
Micron Technology:            Randy Wolff
NetLogic Microsystems:        Ryan Couts
Nokia-Siemens Networks:     * Eckhard Lenski
QLogic Corp.                  James Zhou
Sigrity:                      Brad Brim
                              Kumar Keshavan
                            * Ken Willis
SiSoft:                       Walter Katz
                              Todd Westerhoff
                              Doug Burns
Snowbush IP:                  Marcus Van Ierssel
ST Micro:                     Syed Sadeghi
Teraspeed Consulting Group:   Scott McMorrow
                            * Bob Ross
TI:                           Casey Morrison
                              Alfred Chong
Vitesse Semiconductor:        Eric Sweetman
Xilinx:                       Mustansir Fanaswalla

The meeting was lead by Arpad Muranyi
Minutes taken by Curtis Clark

------------------------------------------------------------------------
Opens:

--------------------------
Call for patent disclosure:

- None

-------------
Review of ARs:

- None

-------------
New Discussion:

Quick question from Ken regarding Backchannel BIRD status:

- Ken: Backchannel BIRD was tabled in IBIS Open Forum.  Next step?
- Arpad: Pull it back here in ATM for review or stay in Open Forum.
- Ken: Anymore feedback?  What's left to do before acceptance?
- Bob: I had syntax objections I'd raised privately.
- Ken: What's the process to move forward?
- Arpad: Feedback, discussion, then vote to have Open Forum move on it.
- Ken: Okay, everyone please help by providing feedback.
- Bob: After the upcoming summit.
- Arpad: I haven't had time to give it a thorough review yet, but intend
         to do it soon.
  - Let's get email feedback to Ken, then we can discuss it.

BIRD 140.1 Corner Clarifications:

- Arpad: Start with the new BIRD (proposing Model_type restrictions)
  - Summarized previous meeting's decision to restrict the Model_type
    - new BIRD reduces number of parameters with corner mapping issues.
  - Very simple new BIRD as written.
  - Discovered a new issue, however.
    - 3-State Model_type should be restricted to AMI Tx.
    - But, I/O has same issue and no way to tell if AMI is Tx or Rx. 
    - How do we know?
    - Should we address this ambiguity?
- Arpad: Walter and Todd privately suggested a solution
  - Restrict Model_Types to Input, Output, Input_Diff, Output_Diff?
- Arpad: This suggestions concerns me.  What about ECLs for example?
- Bob: Don't address it here.  Leave it alone.
  - Address it in 5.2, not hurting anything to leave it alone.
  - Don't want more work for the parser.
- Radek: I/O not really a problem. If enabled it's Tx, else Rx.
- Arpad: No way to know if the [Algorithmic Model] is Tx or Rx.
- Radek: Oh, the .dll name usually makes it clear what the model is.
- Bob: Yes it's an issue, should not be resolved now, new parameter?
- Arpad: Yes, agreed.  Ultimately, we could add a selection parameter
  - Then have both Tx and Rx references in the same [Algorithmic Model].
- Bob: Would bi-directional AMI be a stretch?
- Arpad: Yes, probably a stretch.
  - Would need selection of both Tx and Rx parameters.
  - defining the selection process would be a big effort.
- Radek:  Not a real ambiguity.  Up to the user.
  - Bigger ambiguities in [Diff Pin] vs. differential buffer.
- Arpad: Anyone opposed to moving on with the simple BIRD as is?
  - Do we need another review cycle
  - Wait, don't act on that question until we review other changes.

Move on to changes in BIRD 140.1 itself:

- Arpad: [Diff Pin] keyword, tdelay_*** values are ignored for AMI
  - Do we need more verbiage?
- Radek: intent was to clarify tdelay_*** has no association with corner.
  - We should not force zero to be used at all times.
- Arpad: this is just saying that tdelay_*** ignored for AMI channel
         characterization, normal simulations are not affected
- Bob: Last meeting I had agreed with "just ignore" or treat as zero.
  - These weren't really "corners" they were delay tolerances.
  - Concern now is that this text should go under AMI not [Diff Pin].
  - Any elaboration should also go in AMI.
- Arpad: Partially disagree
  - [Diff Pin] user should immediately see tdelay_*** is ignored for AMI.
- Bob: I guess I'd be okay with adding it in both places.
- Radek: Agree with Bob, keep it separated in AMI.
- Arpad: Open to suggestions.

Move to next section/modification:

- Arpad: for External Model/Circuit
  - "min" Model -> slow/weak
  - "max" Model -> fast/strong
- Bob: Okay with [External Model] (buffers).
  - Not Okay with [External Circuit], might be passive interconnect.
  - Would represent "tolerance" not a "corner" in that case.
- Arpad: isn't "long trace" -> slow corner?
- Bob: yes, could be okay.
- Radek: sounds fine
- Bob: it might render all [External Circuit] parameter selection muddled.
- Arpad: I always thought "min" and "max" kind of odd for External Model
  - this is actually more of a clarification.
- Bob: This runs the risk of making [External Circuit] just another buffer.
  - [External Circuit] has a higher scope (outside Model)
  - strange to tie it to a model/buffer-centric parameter like typ.
- Arpad: Issue is already muddled
  - if user wants all "slow" cases, shouldn't they be able to get slow?
  - slow package and slow buffer for a system analysis?
- Bob: Using the same lingo, what's a strong/fast connector? (Ext Circuit)
- Arpad: low impedance, fast propagation velocity...
- Bob: Could depend, series vs. parallel termination, for example.
- Arpad: an interconnect could be fast/slow from system design perspectives
  - everyone propose suggested text and I'll consider it.

Move on to next section/modification:

- Arpad: (revisiting the "implicitly aligned" section)
  - reiterate "typ/min/max" and reference section 9 on Data Derivation.
- Bob: Changes are good, now acceptable for 5.1.
  - these changes avoid the problem areas we'd run into.
- Fangyi: slow -> "Min", fast -> "Max", is this always true?
  - What about a jitter parameter? Minimum should be fast.
  - What about a Range parameter (AMI).
- Arpad: A jitter parameter is an AMI Format Corner parameter, which doesn't
         require the <slow value> to be smaller than <fast value>
  - It would not need the linkage being defined here with old IBIS analog.
- Radek: Fangyi is saying corner would force "slow" -> "Min" mapping.
  - What would Range do?  We should address them together. 
- Arpad: disagree. AMI List/Range are explicitly independent of Corner.
  - Last sentence in paragraph is saying this.
- Radek: there is a new ambiguity with Range.
- Fangyi: Oh, I see (realizing the source of his confusion)
  - Could we make two things more explicitly clear?
    - Mapping AMI corner to legacy IBIS analog
    - AMI Range/List are independent of Corner.
- Radek: Last sentence is insufficient to clear up Range ambiguity.
- Bob: Range has an entirely different meaning (it's independent of corner)
  - Choosing tap coefficients, for example
  - Range/List are user tunable parameters
- Arpad: I've added extra verbiage (showed the location) detailing these
  - Corner description
  - Range description

Arpad: This has been a good discussion.
 - Those of you who have suggestions or made suggestions please email them.
 - Back to the previous question about proceeding with the new BIRD.
   - Let's go through one more review cycle with this discussion.


Meeting ended.

-------------
Next meeting: 29 Nov 2011 12:00pm PT
(11/15 and 11/22 canceled due to IBIS Asia Summit)

Next agenda:
1) Task list item discussions

-------------
IBIS Interconnect SPICE Wish List:

1) Simulator directives
